OPTOELECTRONIC DEVICE CAPABLE OF PARTICIPATING IN 
IN-BAND TRAFFIC 



The present application claims priority under 35 U.S.C. § 1 19(e) to United States 
provisional patent application Serial No. 60/323,394, filed September 17, 2001. 

BRIEF DESCRIPTION OF THE INVENTION 

The present invention relates generally to optoelectronic devices. More particularly, 
the present invention relates to an optoelectronic transceiver, transmitter or receiver having 
a network address and capable of participating in in-band traffic. 

BACKGROUND OF THE INVENTION 

Fig. 1 shows a schematic representation of the essential features of a typical prior-art 
fiber optic transceiver. The main circuit 1 contains at a minimum transmit and receiver 
circuit paths and power 19 and ground connections 18. The receiver circuit typically 
consists of a Receiver Optical Subassembly (ROSA) 2 which contains a mechanical fiber 
receptacle as well as a photodiode and pre-amplifier (preamp) circuit. The ROSA is in turn 
connected to a post-amplifier (postamp) integrated circuit 4, the function of which is to 
generate a fixed amplitude digital signal that is connected to outside circuitry via the RX+ 
and RX- pins 17. The postamp circuit also often provides a digital output signal known as 
Signal Detect or Loss of Signal indicating the presence or absence of suitably strong optical 
input. The Signal Detect output is provided as an output on pin 20. The transmit circuit 
will typically consist of a Transmitter Optical Subassembly (TOS A) 3 and a laser driver 
integrated circuit 5. The TOSA contains a mechanical fiber receptacle as well as a laser 
diode or LED. The laser driver circuit 5 will typically provide AC drive and DC bias 
current to the laser. The signal inputs for the driver are obtained from the TX+ and TX- 
pins 12. Typically, the laser driver circuitry will require individual factory setup of certain 
parameters such as the bias current (or output power) level and AC modulation drive to the 
laser. Typically, this is accomplished by adjusting variable resistors or placing factory 
selected resistors 7, 9 (i.e., having factory selected resistance values). Additionally, 
temperature compensation of the bias current and modulation is often required. This 
function can be integrated in the laser driver integrated circuit or accomplished through the 
use of external temperature sensitive elements such as thermistors 6, 8. 
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The TX disable pin 13 allows the transmitter to be shut off by the host device, while 
the TX fault pin 14 is an indicator to the host device of some fault condition existing in the 
laser or associated laser driver circuit. In addition, the optoelectronic device 1 may include 
an optional eye-safety integrated circuit 11 that performs functions aimed at preventing non- 
5 eyesafe emission levels when a fault condition exists in the laser circuit. Also shown in Fig. 
1 is an EEPROM 10 for storing standardized serial ID information that can be read out via a 
serial interface (e.g., using the serial interface of the ATMEL AT24C01A family of 
EEPROM products) consisting of a clock 15 and data 16 line. 

10 The signal pins described above collectively provide an electrical interface between 

the optoelectronic device 1 and the host device. The optoelectronic transceiver industry 
over the years has standardized one such interface, known as the GBIC standard. An 
advantage of the GBIC standard is its relative simphcity and the low production cost of the 
integrated circuits required for implementation. Another advantage is that the size of the 

15 transceiver can be quite compact. 

One disadvantage of the GBIC standard, however, is that the transceiver is reliant on 
the host device to perform a variety of operations such as reset and shutdown. If the host 
device malfunctions, the transceiver attached to it may not be able to perform these 
20 operations properly. Another disadvantage of the GBIC standard is its inflexibility. It is 
difficult to implement functionality in addition to those described in the GBIC standard. 

Accordingly, there is a need for a highly flexible interface between an optoelectronic 
device and a host device. 

25 

SUMMARY OF THE INVENTION 

An embodiment of the present invention is an optoelectronic device that has an 
assigned network address (e.g., Internet Protocol address) and participates in in-band traffic 
for purposes of performing functions (e.g., network diagnostics, network control, network 
30 provisioning, fault isolation, etc.) that are traditionally performed by host equipment. An 
optoelectronic device can be an optoelectronic transceiver, an optoelectronic transmitter, or 
an optoelectronic receiver. 

In one embodiment, the optoelectronic device includes a protocol engine and a status 
monitoring module. The protocol engine identifies data packets that are addressed to the 
optoelectronic device, and allows the optoelectronic device to insert packets of information 
generated by the device into in-band data. Logic of the optoelectronic device may modify 
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the operating parameters of the device according to the control information included in the 
data packets. The status monitoring module detects the device's physical conditions and the 
conditions of its links. Status information generated by the status monitoring module may 
be incorporated into the in-band data by the protocol engine such that the status information 
5 may be communicated to a host device or a remote device. The protocol engine is 

programmable to communicate in various network protocols and to perform a variety of 
operations. Thus, additional functionality may be added to the optoelectronic device 
without altering the interface through which the device communicates with the host. 

10 In one embodiment, the optoelectronic device includes an input/output (I/O) 

interface for coupling to a host device, and an optical output interface for coupling to an 
optical medium, such as an optical fiber. Through the I/O interface, the optoelectronic 
device may receive a stream of data that includes data packets. Some of the data packets 
may have destination addresses matching the predefined address assigned to the 

15 optoelectronic device. Circuits of the optoelectronic device identify such data packets and 
process the information (data and/or commands) included in the identified data packets. 
The identified data packets may be removed from the data stream before the data stream is 
converted into optical signals. The optoelectronic device may also include an optional local 
module I/O interface through which the device can communicate with the host or with 

20 another optoelectronic device coupled to the host. 

The optoelectronic device may include an optical input interface. Through the 
optical input interface, the optoelectronic device is configured for receiving a data stream 
that includes data packets, some of which may be addressed to the optoelectronic device. 
25 Circuits of the optoelectronic device identify such data packets and process the information 
included in the identified data packets. The optoelectronic device may remove the 
identified data packets from the data stream before the data stream is communicated to the 
host device. 

30 The optoelectronic device may generate new data packets in response to infonnation 

included in the identified data packets, or in response to the occurrence of a predefined 
event. The new data packets may also be generated periodically. The new data packets may 
be communicated to the host device via the input/output interface, or to a remote device 
whose address is defined by the identified data packets via a computer network. In other 

35 embodiments, the optoelectronic device may be configured to send the new data packets to 
any predefined device or devices via a network. 
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The status monitoring module may include sensors for detecting the physical 
conditions of the optoelectronic device and/or the conditions of the optical medium. The 
detected information may be incorporated into data packets generated by the protocol 
engine. The data packets generated by the protocol engine may be addressed to the host 
5 device and/or to any device coupled to the optoelectronic device via a network. In this way, 
the optoelectronic device is capable of reporting its conditions and/or the conditions of its 
optical links to the host computer or to any remote device in the network. 

BRIEF DESCRIPTION OF THE DRAWINGS 

0 For a better understanding of the invention, reference should be made to the 

following detailed description taken in conjunction with the accompanying drawings, in 
which: 

Fig. 1 is a block diagram depicting a prior-art optoelectronic transceiver. 

Fig. 2A is a block diagram depicting an optoelectronic transceiver in accordance 
5 with one embodiment of the present invention. 

Fig. 2B is a block diagram depicting an optoelectronic transceiver in accordance 
with another embodiment of the present invention. 

Fig. 3A is a block diagram depicting an implementation of a protocol engine 
according to one embodiment of the present invention. 
0 Fig. 3B is a block diagram depicting an implementation of a protocol engine 

according to another embodiment of the present invention. 

Fig. 4 is a block diagram depicting an implementation of the extractor circuit of Fig. 

3. 

Fig. 5 is a block diagram depicting an implementation of the merge circuit of Fig. 3. 
5 Fig. 6 is a block diagram depicting a network having fiber optic transceivers 

remotely coupled to a controller system and a database that stores relevant information of 
the transceivers. 

Fig. 7A depicts a top view of an optoelectronic device in accordance with an 
embodiment of the present invention. 
3 Fig. 7B depicts a side view of the optoelectronic device of Fig. 7A. 

Fig. 8 is a block diagram illustrating a host device that has two optoelectronic 
transceivers that are capable of communication with each other via a local I/O interface in 
furtherance of an embodiment of the invention. 

Fig. 9 is a block diagram depicting an optoelectronic transmitter in accordance with 
5 another embodiment of the invention. 

Fig. 10 is a block diagram depicting an optoelectronic receiver in accordance with 
another embodiment of the invention. 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Fig. 2A shows a schematic representation of a fiber optic transceiver 100 in 
accordance with an embodiment of the present invention. Transceiver 100 includes a 
Receiver Optical Subassembly (ROSA) 102, which contains a mechanical fiber receptacle 
5 as well as a photodiode and a pre-amplifier (preamp) circuit. ROSA 102 is in turn 

connected to a post-amplifier (postamp) integrated circuit 104, the function of which is to 
take relatively small signals from ROSA 102 and amplify and limit them to create a uniform 
amplitude digital electronic output. The postamp circuit 104 provides a digital output signal 
known as Signal Detect or Loss of Signal indicating the presence or absence of suitably 
10 strong optical input. 

The transmit circuitry of transceiver 100 consists of a Transmitter Optical 
Subassembly (TOSA) 103 and a laser driver integrated circuit 105. TOSA 103 contains a 
mechanical fiber receptacle as well as a laser diode or LED. Laser driver circuit 105 
15 provides AC drive and DC bias current to the laser. The signal inputs for the driver are 
obtained firom I/O pins (not shown) of transceiver 100. 

SERDES (SERializing and DESerializing) circuits are incorporated within the 
transceiver 100. SERDES circuits serve the function of converting parallel data to serial 
20 data and vice versa. In the illustrated embodiment, ROSA 102 is coupled to SERDES 
circuitry that includes framing and serial -to-parallel converter circuits 110 and clock 
recovery circuit 1 12. TOSA 103 is coupled to SERDES circuitry that includes parallel-to- 
serial converter circuit 120 and high-speed clock synthesizer circuit 122. 

25 Also contained in transceiver 100 is control circuitry 150, which may include one or 

more integrated circuits configured for controlling the operations of the transceiver 100. 
Control circuitry 150 is coupled to provide control signals to ROSA 102, TOSA 103, post- 
amplifier 104, and laser driver 105, while these components provide feedback signals back 
to control circuitry 150. For example, control circuitry 150 provides signals to control the 

30 bias current level and AC modulation of laser driver circuit 105, while post-amplifier circuit 
104 provides a Signal Detect output to control circuitry 150 to indicate the presence or 
absence of a suitably strong optical input. Other control functions, such as temperature 
compensation of laser driver circuit 105, may also be carried out by the control circuitry 
150. Temperature and/or other physical conditions of various components of transceiver 

35 100 may be acquired using sensors 160 that are coupled to control circuitry 150. In some 
embodiments, conditions of the optical links may be also be acquired using sensors 160. In 
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some embodiments, the control circuitry may include one or more programmble 
microcontrollers and/or microprocessors. 

In addition to, and sometimes in conjunction with these basic control functions, 
5 there are a number of other tasks that may be handled by control circuitry 150. These tasks 
include, but are not necessarily limited to, the following; 

• Setup functions. These generally relate to the required adjustments made on a 
part-to-part basis in the factory to allow for variations in component characteristics such as 
laser diode threshold current. 

10 • Identification. This refers to the storage of an identity code within a general purpose 
memory (e.g., an EEPROM). In a preferred embodiment of the present invention, the 
identity code is stored in the form of an IP (Tntemet Protocol) address. Additional 
information, such as sub-component revisions and factory test data, may also be stored 
within the general purpose memory for purposes of identification. 

15 • Eye safety and general fault detection. These functions are used to identify 

abnormal and potentially unsafe operating parameters and to report these to the user and/or 
perform laser shutdown, as appropriate. Sensors 160 may be used to identify such abnormal 
or potentially unsafe operating parameters. 

• Receiver input optical power measurement. This function is used to measure the 
20 input optical power such that a suitable signal amplification level can be set. 

• Laser diode drive current. This function is used to set the output optical power level 

of the laser diode. 

• Laser diode wavelength control. This function is used to set the wavelength of light 
emitted by the laser diode. This feature is critical in Dense Wave Division Multiplexing 

25 (DWDM) systems. The wavelength of the light emitted by the laser diode, in some 
embodiments, may be changed by adjusting the temperature of the laser diode. 

• Laser diode temperature monitoring and control. In one embodiment, an optional 
temperature controller (e.g., a thermal-electric cooler) may be disposed in or near TOSA 
103 for controlling the temperature of the laser diode. In that embodiment, control circuitry 

30 150 is also responsible for providing control signals to the temperature controller. 

Note that transceiver 100 is configured for coupling to a host device. As used 
herein, a host device refers to a link card to which a transceiver is attached and/or a host 
system computer to which a transceiver provides an optical connection. Host systems may 
35 be computer systems, network attached storage (NAS) devices, storage area network (SAN) 
devices, optoelectronic routers, as well as other types of host systems and devices. 
Transceiver 100 can be attached to a host device through a serial interface. 
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With reference still to Fig. 2A, control circuitry 150 is configured to receive de- 
serialized data from serial-to-parallel converter circuit 1 10. The de-serialized data are 
processed by control circuitry 150 before they are converted into serial data and transmitted 
to the host device. Specifically, control circuitry 150 monitors the stream of data that it 
5 receives from serial-to-parallel converter circuit 1 10 (an "inbound" data stream) and 

determines whether the data contains any information intended to be communicated to the 
transceiver 100. If such information is identified, control circuitry 150 retrieves the 
information from the "inbound" data stream and performs operations according to the 
identified information. In response to the identified information, control circuitry 150 may 
10 modify the "inbound" data stream by removing the identified data packets and/or by 
inserting new data packets in the data stream. 

In this document, the term "data packet" is used broadly to mean all packets of 
information transmitted over a data path. Thus, "data packets" includes protocol packets, 
15 packets having only command information, and the like, as well as packets containing data 
being transmitted over a data channel. 

For the purposes of illustration, assume that transceiver 100 is assigned an IP 
address, and transceiver 100 is configured for coupling to an IP network. The data stream 

20 that passes through control circuitry 150 will include data packets each having a packet 

header and a destination address. Data packets having a destination address matching the IP 
address assigned to transceiver 100 are retrieved from the data stream by control circuitry 
150. These data packets may include, within their payload portions, commands to report the 
transceiver's current status information to the host device or to a specific IP address, for 

25 example. In another example, these data packets may include commands to adjust the bias 
level of laser driver 105, or adjust the wavelength of the emitted light. Control circuitry 
150, upon processing these data packets, will perform the indicated operations. Data 
packets that are not addressed to transceiver 100 will pass through unmodified. 

30 In some embodiments of the invention, the control circuitry 150 is configured to 

receive an "outbound"data stream from the host device. In this embodiment, "outbound" 
serial data from the host device are de-serialized by SERDES circuits before they are 
transmitted to the control circuitry 150. Control circuitry 150 monitors the de-serialized 
"outbound" data stream and determines whether the data stream contains any information 

35 intended to be communicated to the transceiver. If such information is identified, control 
circuitry 150 retrieves the information from the "outbound" data stream and performs 
operations according to the identified information. In response to the identified 
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information, control circuitry may modify the "outbound" data stream by removing the 
identified data packets and/or by inserting new data packets in the data stream. The 
"outbound" data stream is then provided to parallel-to-serial converter circuit 120 to be 
serialized and subsequently converted to optical signals by TOS A 103. 

5 

In some embodiments of the present invention, control circuitry 150 is configured to 
process both "inbound" and "outbound" data streams. In these embodiments, information 
from one data stream may effect modification of another data stream. For example, from 
the "outbound" data stream, the transceiver may receive a command to report its operating 

10 parameters to the host device. In that event, the transceiver may generate a data packet 
containing its operating parameters and send the data packet to the host device via the 
"inbound" data stream. In another example, the transceiver may receive from the "inbound" 
data stream a command to report its operating parameter to a specified network address. In 
that event, the transceiver may generate a data packet containing its operating parameters 

15 and send the data packet to the specified network address via the "outbound" data stream. 

In furtherance of the present invention, transceiver 100 may generate data packets to 
be communicated to the host device or to a remote device upon the occurrence of a 
predefined event. For example, when sensors 160 detect an unsafe operating condition, 

20 transceiver 100 may attempt an emergency shut down. In that event, transceiver 100 may 
generate data packet(s) indicating the shut down and send the data packet(s) to the host 
device and/or a remote device via another network connection of the host. In another 
example, when sensors 160 detect that the wavelength of light emitted by the laser diode of 
TOSA 103 has deviated significantly, transceiver 100 may generate a data packet containing 

25 a warning signal to the host device or a remote device via another network connection of the 
host device. In yet another example, when sensors 160 detect that a laser diode of TOSA 
103 is exhibiting symptoms known to be predictive of future failure of the laser diode, 
transceiver 100 may generate a data packet indicating the condition of the laser diode and 
send the information to the host device and/or remote device. In some embodiments, 

30 transceiver 100 may be configured to send data packets containing status information to the 
host device and/or a specified remote device periodically. In another embodiment, the 
transceiver 100 may be programmed to send an electronic message (e-mail) to a particular 
IP address upon encountering an error condition. 

35 In accordance with one embodiment of the invention, transceiver 100 does not 

communicate exclusively using data packets. Also shown in Fig. 2A is an optional local 
module input/output (I/O) interface through which the transceiver may communicate with 
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the host device. In this embodiment, transceiver 100 may be configured to transmit its 
status information (e.g., information generated by sensors 160, Loss of Signal, etc.) and 
network address to the host device via the local module I/O interface such that the host 
device can forward the information to another address via the host device's other network 
5 connections. Communication via the local I/O module can be used for reporting link 
failures. For instance, if the optical link coupled to transceiver 100 is interrupted, 
transceiver 100 may communicate the link's condition and its network address to host 
device. The host may then forward the link's condition to the network administrator, the 
party who is responsible for maintaining the link, or a centralized network control system. 

10 

Using the local module I/O interfance, transceiver 100 can serve as a conduit of 
information for all optoelectronic devices within the same host. Fig. 8 is a block diagram 
illustrating such a configuration. As shown in Fig. 8, a host device 800 with two 
transceivers Transceiver A and Transceiver B coupled thereto includes a local module I/O 
15 bus 8 10 for allowing Transceiver A to conununicate with Transceiver B via the local 
module I/O interface. Status information of Transceiver B may be communicated to 
Transceiver A via the local module I/O interface such that the status information can be 
communicated to the host device or a remotely coupled device via in-band data of 
Transceiver A. 

20 

Furthermore, Transceiver A can be a transceiver capable of participating in in-band 
data communication (e.g., transceiver 100), and Transceiver B may be a transceiver that is 
not capable of participating in in-band data communication. Multiple transceivers that are 
not capable of participating in in-band data communication by themselves may be coupled 
25 to the host device and may participate in in-band communication through Transceiver A as 
long as these transceivers are capable of communicating via the local module I/O interface. 

Fig. 6 is a block diagram illustrating a control system 600 coupled to receive status 
information of multiple transceivers 610 to which the control system 600 is remotely 

30 coupled via a packet-switched network 690. Transceivers 610 have IP addresses different 
from those of their associated host devices 620. The IP addresses of transceivers 610 are 
stored within a database 605 of the control system 600. The control system 600 may 
periodically send status update requests to the transceivers 610 in data packets addressed to 
transceivers 610. The status update requests may include the IP address of the control 

35 system 600. Thus, upon receiving the status update requests, the transceivers 610 may 
respond by sending their status information to the control system 600. A centralized 
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database of transceiver status information may then be maintained by the control system 
600. 

In furtherance of the present invention, control system 600 may remotely control the 
5 operation parameters of transceivers 610. This feature is useful for system administration 
and enables remote trouble-shooting of transceiver problems. This feature is also useful for 
centralized control of network parameters and resources, such as transmission wavelengths 
in a DWDM system. 

10 Attention now turns to implementation of control circuitry 150. Fig. 3A is a block 

diagram depicting portions of control circuitry 150 in accordance with one implementation 
of the present invention. Particularly, a protocol engine 350 that includes an address 
memory 210, an extractor 212, a merge circuit 214, an IN buffer 216, an OUT buffer 218, a 
merge controller 220, an instruction and program memory 222, a processor 224, and a 

15 sensor data storage 226, is illustrated. 

Address memory 210, which may be an EEPROM (Electrically Erasable and 
Programmable Read Only Memory) or any type of non-volatile memory, stores a network 
address of the transceiver. The extractor 212 receives a stream of data packets and 
20 compares the network address of the transceiver with destination addresses of the data 

packets received. If there is a match, extractor 212 extracts the matching data packets from 
the data stream, and stores the extracted data packets within the IN buffer 216. The 
remaining data packets, which do not have a destination address matching the network 
address of the transceiver, are passed to merge circuit 214. 

25 

Instruction and program memory 222 contains programs and/or instructions, for 
execution by the processor 224, for decoding and processing data packets addressed to the 
transceiver, for analyzing data received from the sensors 160, for modifying the operational 
state of the transceiver (e.g., by modifying the bias applied to the laser diode by laser driver, 

30 and/or by activating and deactivating various circuits within the transceiver), and for 

generating new data packets addressed to the host device or other network device. In one 
embodiment of the invention, these programs and instructions contained in memory 222 
may be modified by the user(s) such that the optoelectronic device may be reprogrammed to 
communicate in various network protocols and to perform a variety of operations. By 

35 altering the program codes contained in memory 222, additional functionality may be added 
to the optoelectronic device without altering the interface through which it conomunicates 
with the host. 
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With reference still to Fig. 3A, data packets extracted by the extractor 212 are 
replaced with link idle symbols at the output so that the link is kept active and error free. 
The extracted data packets are processed by processor 224 in accordance with the program 
codes stored within memory 220 and/or operational state(s) of the device. In the present 
5 embodiment, processor 224 may process the information contained in the data packets in 
conjunction with instructions stored within instruction and program memory 222 and/or 
sensor data stored within sensor data storage 226. For example, the extracted data packets 
may contain an instruction that calls for an operation defined by the program codes stored 
within the instruction and program memory 222. In another example, the extracted data 
10 packets may contain an instruction that instructs the transceiver to obtain sensor data from 
sensor data storage 226, generate a status report of its current operating conditions and 
transmit the status report to a specified network address. In yet another example, the 
extracted data packets may contain new processor instructions to be stored within 
instructions and program memory 222. 

15 

Data packets generated by processor 224 are temporarily stored within OUT buffer 
218. Merge circuit 214, under the control of merge circuit controller 220, merges the 
processor-generated data packets with data packets that are not addressed to the transceiver 
to form a modified data stream. If processor 224 does not generate any new data packets, 
20 the merge circuit forms a modified data stream with the data packets that are not addressed 
to the transceiver. In the present embodiment, the merge circuit 214 inserts processor- 
generated data packets into other data packets by monitoring the data stream and replacing a 
protocol suitable number of link idle symbols with the processor-generated data packets. 

25 Observe that protocol engine 350 of Fig. 3A is configured for processing and 

modifying one data stream. A fiber optic transmitter or receiver having a single datapath 
may implement the circuitry of Fig. 3A. A fiber optic transceiver having multiple datapaths 
may implement one or more instances of the protocol engine 350. 

30 Fig. 3B is a block diagram depicting an implementation of a protocol engine 350' for 

a fiber optic transceiver having two data paths. The control circuitry is configured for 
processing and modifying more than one data stream. In addition to the control circuitry 
shown in Fig. 3 A, the protocol engine embodiment of Fig. 3B includes a second extractor 
232, IN buffer 236, OUT buffer 238 and merge circuit 240. The first set of circuits (212, 

35 214, 216, 218, 220) are used with a first data path (e.g., the inbound data path), while the 
second set of circuits (232, 234, 236, 238, 240) are used with a second data path (e.g., the 
outbound data path). Data packets with a destination address matching the network address 
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of the transceiver are extracted from the data streams and processed by processor 224. Data 
packets generated by processor 224 may be inserted in any one of the data streams, 
depending on the intended destination of the processor-generated packets. In this way, a 
response triggered by a data packet sent by the host device can be directed back to the host 
device quickly. 

Fig. 4 is a block diagram depicting an implementation of an extractor circuit 212 in 
accordance with one embodiment of the present invention. Extractor circuit 212 consists of 
a FIFO (First In First Out buffer) 310, a demultiplexer (demux) 312, a comparator 3 14, and 
extractor control logic 316. FIFO 310 is configured to receive and temporarily store a 
stream of data packets. While the data packets are progressing through FIFO 310, a 
comparator examines the destination address bits of each packet, and compares the 
destination address of each packet with the network address of the transceiver. If a match is 
found, comparator 314 triggers extractor control logic 316 to send an appropriate signal to 
the demux 312 such that the matching data packet is diverted to the IN buffer 216. The 
non-matching data packets are provided to demux 312 to be passed onto merge circuit 214. 

The comparator 314 also detects the end of each packet and sends an EOF signal to 
the extractor control logic 316 when the end of a packet has been conveyed to the IN buffer 
216. This helps the extractor control logic 316 to control the diversion of variable length 
packets to the IN buffer 216, by enabling it to know when the end of such packets have been 
fully transferred from the FIFO 310 to the IN buffer 216. In an alternate embodiment, all 
packets addressed to the transceiver (i.e., having a destination address matching the address 
assigned to the transceiver) are fixed length packets, thereby eliminating the need for end of 
packet detection circuitry in the comparator 314. In yet another alternate embodiment, the 
length of each packet addressed to the transceiver is specified in the header of the packet 
and that length information is extracted (e.g., by the comparator 3 14 or a parallel circuit) 
and conveyed to the extractor control logic 316 to enable it to handle the transfer of variable 
size data packets from the FIFO 310 to the m buffer 216. 

Fig. 5 is a block diagram depicting an implementation of a merge circuit 214 and 
merge controller logic 220 in accordance with one embodiment of the present invention. 
Merge circuit 214 consists of FIFO buffers 510, 520 and a multiplexer (mux) 530. FIFO 
510 receives a data stream from extractor circuit 510, and FIFO 520 receives a data stream 
from OUT buffer 218. As mentioned, data contained in OUT buffer 218 are generated by 
processor 224. The FIFOl and FIF02 buffers 510, 520 include circuitry for generating 
fullness indication signals Fullnessl and Fullness2, respectively, which indicate the fullness 
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of these buffers. The Fullness2 signal indicates when a full packet from the processor 214 
(see Figs. 3A, 3B) is present in FIF02. The Fullnessl signal indicates when FIFOl contains 
less than a threshold level of data. For example, Fullnessl may indicate when FEFOl is at 
least half empty. Alternately, Fullnessl may indicate when FIFOl is sufficiently empty to 
enable transmission of a full data packet from FIF02 without risking overflow of FIFOl by 
new incoming data. In this regard, it is noted that "filler" signals, sometimes called "idles" 
or "null data signals," are transmitted on the data paths between data packets, but are not 
stored in the FIFO's of the transceiver. When data packets are transmitted at less than the 
maximum transmission rate of the data channel, the FIFO's in the data path become 
partially or even completely empty. 

A first comparator 522 sends an EOFl signal to the merge control logic 316 when 
the end of packet is transferred from FIFOl to the Mux 530, and a second comparator 524 
sends an EOF2 signal to the merge control logic 316 when the end of packet is transferred 
from FIF02 to the Mux 530. Mux 530 selectively outputs data from either FIFO 510 or 
FIFO 520, depending on the SRC_Select signal generated by merge controller logic 220, 
which generates the SRC_Select signal based in part on the Fullnessl and Fullness2 signals 
from the FIFO's 510, 520. When both FIFOl and FIF02 are empty. Mux 530 generates and 
outputs filler signals (e.g., idles) to the output data stream. 

In addition to generating the SRC_Select signal, merge controller logic 220 
generates clock signals ReadClkl and ReadClk2 for controlling the outflow of data from 
FIFO 510 and FIFO 520. In particular, when the Fullness2 signal indicates that a full packet 
(produced by the data processor 224, Fig. 3A or 3B) is ready for transmission, the Fullnessl 
signal indicates that FIFOl is less full than the predefined threshold, and the EOF signal 
from comparator 522 indicates that the last symbol transferred from FIFOl to the Mux 530 
was the end of a data packet, then the merge control logic 316 stops the outflow of data 
from FIFOl (by deactivating ReadClkl) and enables the outflow of data from FIF02 (by 
activating ReadClk2) until a full data packet is transferred from FIF02 to the Mux 530. 
When a full data packet has been transferred from FIF02 to the Mux 530, as indicated by 
the EOF2 signal, the merge control logic 316 determines whether to next send a data packet 
from FIFOl or FIF02 based on the current status of the Fullnessl and Fullness2 signals. 
When both FIFOl and FIF02 are empty, a filler signal is sent from either FIFO to the Mux 
530, thereby causing the Mux 530 to transmit filler signals until such time that it receives a 
new data packet from either of the FIFO's. 
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Figs. 7A and 7B illustrate the dimensions of an optoelectronic device 700 that may 
be constructed in accordance with embodiments of the present invention. Fig. 7A shows a 
top view of the optoelectronic device 700, and Fig. 7B shows a side view. The physical 
dimensions of the optoelectronic device 700 are as follows: width, 3 cm or less; length, 6.5 
5 cm or less, and height, 1 cm or less. In an alternate embodiment, the physical dimensions of 
the optoelectronic device 700 are: width, 0.54 inches or less; length, 2.24 inches or less; and 
height, 0.34 inches or less. Optoelectronic device 700 includes an electrical interface 702 
for coupling to a host device and a circuit board 704 containing SERDES circuits (e.g., 
clock recovery circuit 112, framing and serial-to-parallel circuit 1 10, high-speed clock 

10 synthesizer circuit 122, parallel-to-serial converter circuit 120, See Fig. 2A) and control 
circuitry. Note that the SERDES circuits and the control circuit 150 including processors, 
A/D converters, D/A converters, protocol processing circuits, FIFOs, program memories, 
etc., may be implemented as a single integrated circuit. Coupled to the circuit board 704 are 
optical subassemblies 706 (e.g., ROSA 102 and TOSA 103) and the optical connectors 710 

1 5 for coupling to fiber optic cables. 

Attention now turns to Fig. 2B, which depicts a schematic representation of a fiber 
optic transceiver 101 in accordance with an alternate embodiment of the present invention. 
Fiber optic transceiver 101 is similar to fiber optic transceiver 100. One difference, 
20 however, between transceiver 101 and transceiver 100 is that transceiver 101 is configured 
for coupling to the host device via a parallel interface. Thus, SERDES circuits for 
serializing and de-serializing data between the host device and transceiver 101 are omitted. 

Some embodiments of the present invention described above include optoelectronic 
25 transceivers that have one datapath for in-bound network traffic and another datapath for 
out-bound network traffic. But the present invention is not limited to transceivers. Rather, 
embodiments of the present invention include optoelectronic transmitters and optoelectronic 
receivers that are capable of participating in "in-band" communication. 

30 Fig. 9 is a block diagram depicting an optoelectronic receiver 900 in accordance 

with another embodiment of the invention, and Fig. 10 is a block diagram depicting an 
optoelectronic transmitter 910 in accordance with another embodiment of the invention. 
Implementation of optoelectronic receiver 900 and optoelectronic transmitter 910 is 
substantially similar to that of transceiver 100. A difference, however, is that transmitter 

35 900 is not configured to receive optical signals, and that receiver 910 is not configured to 
transmit optical signals. 
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The foregoing descriptions of specific embodiments of the present invention are 
presented for purposes of illustration and description. They are not intended to be 
exhaustive or to limit the invention to the precise forms disclosed, obviously many 
modifications and variations are possible in view of the above teachings. The embodiments 
5 were chosen and described in order to best explain the principles of the invention and its 
practical applications, to thereby enable others skilled in the art to best utilize the invention 
and various embodiments with various modifications as are suited to the particular use 
contemplated. 
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